Many types of electronic devices require that information be loaded from a source and stored in a memory. For example, programmable logic devices are configured to implement a desired logical function based upon configuration data provided by a programming tool. The configuration data may be stored internally for a non-volatile device or externally for a volatile device. Regardless of whether the configuration data is stored internally or externally, the increasing complexity of programmable logic devices requires larger and larger amounts of configuration data. This increased configuration data size produces delays in the configuration process and increases the costs.
During the configuration process, the configuration data is typically serially-shifted into the devices responsive to cycles of a clock signal. For example, it is common to have one bit of the configuration data shift in for each clock cycle. As seen in FIG. 1, the configuration data is shifted into a shift register 100 as serial data 110. When the shift register has been filled, the contents are transferred in parallel to a memory 120. For example, should shift register 100 be thirty-two bits long, thirty-two bits of serial data 110 would be shifted into shift register 100 responsive to thirty-two cycles of clock signal 125. The resulting thirty-two bit word stored within shift register 100 is then transferred into memory 120, whereupon another thirty-two bits of data may shift into shift register 100, and so on.
To reduce the storage requirement for the configuration data, the configuration data may be compressed. In addition, the compression of the configuration data decreases the amount of time needed to configure the corresponding programmable logic devices. Because a programmable logic device is very sensitive to errors in the configuration data stream, any compression of the data must be lossless or perfect such that the decompressed configuration data is exactly the same as the configuration data before compression. Because of the requirement for perfect compression, only a portion of the configuration data can generally be compressed. Thus, the configuration data being shifted into the device will comprise both uncompressed and compressed data. This mixed nature of the configuration data complicates the configuration data flow described with respect to FIG. 1. Any compressed configuration data must be decompressed before configuration may be completed. But recall that the configuration data is being shifted at a constant rate responsive to cycles of the clock signal. When data is decompressed, this constant rate must necessarily change. This adds complexity to the configuration process because it must accommodate the rate changes depending upon whether configuration data being shifted in was compressed or not. This accommodation may take place in the programming tool providing the bit stream or may take place within the device. Regardless of where the accommodation takes place, it adds considerable complexity to the configuration circuitry and the software controlling the configuration process. Moreover, this complexity inherently limits the bit rate of the configuration data stream. As a result of this complexity, comparatively few programmable devices utilize configuration data compression, particularly in low-cost devices.
Accordingly, there is a need in the art for improved decompression techniques for data streams.